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Attached is the draft of the Programming Conventions subsection (2.2) of the Software 
Development Procedures section of the SDD Policies and Procedures document. 

The concept of a Programmer's Notebook is introduced in the attached subsection and refers to 
the collection of reference and training materials that every programmer in SD should have. 
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considered a necessary repository for related memorandum, notes, etc. The outline and content 
of this notebook is not discussed here because it is more appropriately addressed in the context 
of training or reference materials for the staff than in a discussion of programming conventions, 
though materials that are described as in the Programmer's Notebook will simply be attachments 
that follow the subsection. The exception is the reference to good coding examples which are 
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object for himself and with a few modifications, we could adopt it for SD?) 
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2.0 SOFIWARE DEVELOPMENT PROCEDURES 

2.1 Documentation Conventions 

This section will be completed at another time with another set of text. 

2.2 Programming Conventions 

Introduction; 

The purpose of these conventions is to support the software generation effort so the code 
produced will: 

o Facilitate the creation of the software components of the OIS products. 

o Be portable among the technical staff. 

o Be extensible and maintainable over the life of the product. 

In addition, we expect these conventions to be easy to train new staff members to use. 

The conventions presented are, for the most part, not a radical deviation from many 
practices of our experienced staff, nor do they diverge dramatically from the literature on 
accepted software engineering conventions and practices. Adherence to this set of 
conventions is expected to have long-term gains in the development and on-going 
maintenance of software that should offset any short-run setbacks that result from 
modifying existing code, modifying work habits, or adjusting to different coding rules. 

The three areas of programming conventions described are: format conventions, naming 
conventions, and coding conventions. The concept of general and special conventions 
underlies the description of these Programming Conventions. Generql__Conven[[qns apply to 
all the code generated and are explicitly defined in the description of each area. Special 
Conventions apply to logical subsets of the software development effort -- for a specific 
system, such as Pilot -- and the description of currently available special conventions will be 
included in The Programmer's Notebook Templates are predefined form files which contain 
the skeleton for program or data modules. The skeleton includes program delimiters such as 
PROGRAM .... END, and it may also contain placeholder text which can be replaced by 
actual names. Dictionaries contain both rules for generating names and definitions for 
special technical terms or words with specialized meaning. Templates and dictionaries can 
be enhanced by descriptions of specific coding rules to which a project will adhere. Existing 
templates, dictionariees, and supplimental coding rules are contained in The Programmer's 
Notebook (see attachment A, «# and JSfor Diamond, Mesa Runtime, a^nd Tools conventions, 
respectively). 



Special conventions are not a way to subvert general conventions. They are well defined 
rules to guide the programming activity and are implemented through the definition and 
description of specific coding conventions, programming templates, and dictionaries, which 
identify structures, naming rules, and definitions of technical or special terms that apply to 
the software development effort The staff on a particular project may create a set of special 
conventions for the system they are working on if their needs cannot be met by using a set 
(or subset) of existing special conventions. We expect new sets of special conventions to be 
introduced infrequently. Special conventions must be approved and published for inclusion 
in The Programmer's Notebook. 
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Since the reader is assumed to be familiar with the programming language documentation, 
references to language characteristics are not included in this section. t 



Format Conventions 
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The objective of formatting conventions is to facilitate readable code, 
conventions that apply to formatting are: 
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The general 




o The editor used to create code is BRAVO re 



§e 6.0 or a follow-on editor. 




Each statement is a separate BRAVO paragraph, is A^Sc^Ur^S&<M rc^** .^^^4/] 
All indentation is done using the Looks nesting command and preset margins. 7 * tn ^**&\ 



o Comments: Comments appearing at the right of some construct refer only to that 
construct, except for comments appearing to the right of a begin which apply to the 
block. Longer comments are in paragraph form and refer to the program text which 
follows. (Do Not begin each line with "--" as this makes updating difficult.) 

o Spacing: 

1. A space should be placed after a comma, semicolon, or colon, but not 
before. 

2. No spaces should be placed around brackets or parentheses. 
Exceptions to this are: a) there should be spaces between declaring words 
such as record, procedure, and return and the adjacent brackets; and 
b) there should be equal amounts of space next to matching brackets and 
parentheses that are hard to spot. 

3. Equal amounts of space should be placed on each side of <- or any 
binary operator that connects two lengthy expressions. 



o Indentation and Line Breaking 

ft &»PJJ O ¥^'t $"f/ tep 

1. Use rafcataii^n commands, not tabs. 



2. Write no more than one statement on a line, except where several 



short statements are logically one. 

temp <- x; x «• y; y <- temp; 
WriteString[s]; WriteChar[CR]; 

3. Indent the labels of a SELECT (including the ENDCASE) one level, and 
the statements a second level (unless a statement will fit on the same line 
with the label). 

SELECT e FROM 
easel => s; 
case2 =•> 

lengthy 
statement; 
case3 => 

BEGIN 

END 

ENDCASE 

4. Indent one level for the statement following a THEN or else (unless it 
fits on the same line). Put then on the same line as if, and indent ELSE 
the same amount as IF. If the else is followed by another IF, write both 
on the same line. 

IF condition THEN consequence ELSE alternative 

IF condition THEN consequence 
ELSE alternative 

or 

IF conditionl THEN consequence 

ELSE IF condition2 THEN alternative 

ELSE 

BEGIN 

END ^f^ ^^ 

/ 

5. Consider using a SELECT TRUErather than a string of ELSE IFs for 
readability. 

SELECT TRUE FROM 
conditionl => 
lengthy 

consequence 
condition2 => 
lengthy 

alternative 
ENDCASE => 
BEGIN 

END 

6. A compound should be either all on one line or one item per line. A 



compound should be indented from the surrounding material. 

BEGIN s; s; END 

BEGIN 
s; 
s; 
END 



DO s; s; ENDLOOP 

<- DO 

s; 
s; 
ENDLOOP 

7. A record declaration should be either all on one line or one 
identifier list per line with the brackets on separate lines. 

Bla: TYPE = RECORD[x: Dictionary, y, z: INTEGER]; 

Bla: TYPE = RECORD 

[ 

x: Dictionary, 
y, z: INTEGER 

]; 

8. A procedure declaration should have the BEGmand END on separate 
lines. "** "**"""" 

SomeProc: PROCEDURE[x: Ta, y, z: Tb] RETURNS [Tc] = 

END (oU W i//^«J™rf'^'-3 

9. If a procedure declaration will pot fit onr one line move the 
RETURNS clause to a second linehndented^one space). If either the 
PROCEDURE [arglist] clause or the RETURNS [retlist] clause will 
not fit on a single line, break it into one line for each member of the 
arglist or retlist, respectively, with the enclosing brackes, [], on separate 

lines - j^s+P^jraWHe^ . . . 

SomeProc: PROCEDURE [x: Ta, y, z: Tb] 

RETURNS [Tc] = a C i f ' £ CW) I * 

BEGIN «-^^4 t&QnM kfS K% "fc> Vd/ fikg 

END 

The following illustration assumes the arglist will not fit on one 
line or that the author wishes to comment the arguments. 



SomeProc: PROCEDURE 
r 

SomeProc: PROCEDURE [x: Ta, y, z: Tb] 
RETURNS [Tc] = 

BEGIN ^- 






END 
x: Ta, 
y, z: Tb 

] 

RETURNS [Tc] » 
BEGIN 

END 

10. A long statement should be broken into many lines by: a) rewriting it 
as several statements, b) indenting the arguments of the main procedure 
call or record constructor as one would indent the components of a long 
record declaration, or c) breaking the statement into lines at reasonable 
places and indenting the continuation lines one space in from the initial 
line. 

Example of a rewrite of several statements: 

a <- TheFirstProc[TheSecondProc[...], TheThirdProc[...]]; 

temp2 «• TheSecondProc[...]; 

temp3 <- TheThirdProc[...]; 

a <- TheFirstProc[temp2, temp3]; 

Example of indenting the arguments of the main procedure call or 
record constructor as one would indent the components of a long 
record declaration: 

a «- TheFirstProc 

c 

TheSecondProc[...], 
TheThirdProc[...] 

J» 

Sample of breaking the statement into lines at reasonable places and 
indent the continuation lines one space from the initial line: 
a <- TheFirstProc[ TheSecondProc[...], 
TheThirdProc[...] ]; 



The special format conventions are: 



o There are no Standard Fonts. A project creating a system, such as PILOT, may 
decide upon a standard font and should include this in the programming 
documentation for the system. 






o Use of specialized text features, other than the indentation command of BRAVO, 
should be minimized (for example, forcing page boundaries). 



Naming Conventions 

The objective of naming conventions is to provide a meaning to the names in the code. 



The general conventions are: 

o Capital Letters: Type, procedure, label, module, and signal names start with a 
capital letter, all else starts with a lower case letter. 

o Compound names: Each component is captialized (e.g., maxFilePage) in 
compound names. 

o Procedure with side effects (such as changes to the abstract state of its 

object): The procedure name begins with a verb (except "is" ani "has"); a _ C-f Al&/6 

otherwise, verb/noun naming is preferredr b*+W*+ rfiggjjj^ ft^yJl C *&M**!< •* \kV vv j 




dictionary.lnsert[word] ViSftWtHe***^ Ut*>#r 

stream.Get[] 
5 pool.ObtainBufferWhichHas[virtua!Addr] i 
As opposed to: AAX j&ltiH* 

dictionary.IsEmpty[word]~ use dictiobary.€Ht*H*Word[word] ~1 * 4* 

dictionary.Has[word]--use dictionary .stetWord[word] )H fAt^T* 

dictionary.Meaning[word]~-use dictionary .SetMeaning[ word] I 
stream.CurrentPos[i]— use dictionary .SetPos[i] ™°* 

o Abbreviations: If used, the standard prefixes are: 

p* pointer to a * 

i* index of something in a * 

1* length of a * 

n* number of *'s 

Any other special abbreviations appear in a section in a dictionary. 
o Signaffand Errors: Precede an invocation of a signal or error by the word signal 

Or ERROR. 



Special naming conventions may appear in a project dictionary and include: 

o Additional rules for contructing names. 

o Technical or special terms that are used for naming. 

Coding Conventions 

Except for the restrictions contained in the language manuals which reflect language 
constraints, the coding rules to which we expect the projects to adhere can be found in books 
or articles such as The Elements of Programming Style (Kernighan and Plaguer), and the 
redundancy of repeating those in this section is nof necessary. 4fys^M;^otte-(-tW0-oi^T^). 
acceptable reference(s) of programming wisdom *dfteti44 be selected and made available 4e our 
Sa^ feknis B^vel^pmefvt-^T^iioan^en t. (Aftefr4kis4*u^^ 

^hoxild^be^giAte*^^ Copies of good 

illustrations of practices we would like to see {coding literature!) will be contained in The 
Programmer's Notebook 
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APPENDIX A: MESA Formatting Rules for DIAMOND 



"Rules of programming style, like those of English, are sometimes broken, even by the best writers. When a 
rule is broken, however, you will usually find in the program some compensating merit, attained at the cost of 
the violation. Unless you are certain of doing as well, you will probably do best to follow the rules." 
(Kernighan/Plaguer/Strunk/White) 



1. No special formatting (bold, fonts, etc.) except in comments if there is a real need. 

2. Tabs are used for indentation (standard tab width is 55pt). — -Q^ 

3. Punctuation rules are similar to those in the Mesa manual: 

a space (or carriage return) after a comma, semicolon, or colon and none before. 
However in declarations, a colon may be followed by a tab (see below). 

no spaces (immediately) inside brackets or parenthesis. Space should be left between 
reserved words and [: RETURN []; 

spaces should be written around binary operations at the outermost level, e.g. «- in an 
assignment statement, < in a conditional statement, + in a «- a + 1; When embedded in 
expressions, parameter lists and so on, it is recommended (but not required) that spaces 
be omitted, 
(as in n «■ IF (n«-n+l)<nMac THEN nl ELSE n2;) 

spaces are not written around . and .. 

4. In general, indentation should be used sparingly, only when dictated by the logical structure. 
If a long identifier or expression pushes a delimiter beyond the correct level of indentation, 
that delimiter should be written on a new line. Indentation rules for statements are (almost) 
according to the Mesa manual (pl37). These rules are best summarized in the following 
examples: 

IF a < aMac THEN a «- aNil; — short statement 

IF a < aMac THEN 
BEGIN 
a «- aNil; 
END 
ELSE IF a < aMax THEN 
BEGIN OPEN x; 
a <- aNil; 
EXITS 

End => a «- al; — Label naming is explained below 
NoMoreEntries => 

BEGIN 

a <~ a2; 

END; 
END; - OF OPEN x 

FOR a IN [0, aMac) 
DO 

PrintA(a); 
ENDLOOP; 

SELECT a + da FROM 



aNil => 
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aFirst = 
, ^>IN [aFirstfree..aLastfree] => 
rr a <- aNil; 

^ ENDCASE; 

5. Comments may appear to the right of some construct, preceded by a tab, and then they may 
refer only to that construct. Longer comments appear on separate lines, without indentation, 
referring to the program text which follows. 

6. In other declarations, the type is preceded by a tab: 

a: INTEGER = al; 

a, ta: INTEGER; 

bmpicergcaLast: INTEGER; 

Records (and procedures, see below) are declared as follows: 

B: TYPE = MACHINE DEPENDENT RECORD 

[a: A, 

pa: Pa, 

aLastfreemac: A 

]; 

C: TYPE = MACHINE DEPENDENT RECORD 

[a: A *- aNil, 

VARIANT: 

SELECT vr: VrC FROM 

vrCl => [b: B, 

d: D 

]. 

vrC2 => NULL, 

ENDCASE 

]; 

Note that the variant part has the standard name VARIANT by convention. The naming of 
the variants is explained below. 

If the type includes indenting (procedure or record type), type should start strictly one level 
. indented from the (possibly long) name: 



LongProcedureName: 




PROCEDURE 




[a: 


A, 


b: 


B, 


c: 


c, 


d: 


D 


]; 





7. Procedure declaration format is defined in the Module template. Note that in the common, 
non-local, procedures, some of the outermost levels of indentation are omitted by convention, 
so that the procedure bodies may start without any indentation. 

Procedures with simple parameter lists may be declared in a single line: 

PROCEDURE [a: A] RETURNS [A] = 

while more complex procedures should be declared in the same format as two records: one 



12 

containing the parameter list, and the other the returned values. 



PROCEDURE 




[a: 


A, 


b: 


B, 


c: 


c, 


d: 


D 


] 




RETURNS 




[A. 




B, 




C 




] = 





8. Pack and Module formats are described in the module templates. Emphasis to procedure 
names in heading comments is given by expanding and capitalizing IN THIS WAY. 
Characters originally capitalized should be preceded by en extra blank; 

X Y I N I T. , / _^ 

9. Continuation lines are indented by/twd blanks. For example: I U*^& ^ r *\ 

W? a «- al + a2 + a3 + I U I 4A \>K 
a4 + a5; ^Ji 

v —* 

10. Variable and constant names start with a lower case letten* type, procedure, label, module, 
and signal names start with a capital letter. Reserved words feven if reserved by convention) 
are fully capitalized. ^ 

11. Variable and constant names consist of a type tag and or more modifiers. The type tag 
may not contain capitals. The first letter of each of the modifiers (if any) is capitalized. 
Some type tags are standards, others may be defined in the meta-prograrns. New type tags may 
be constructed using standard constructors which are described below. Type tags are usually 
defined to be very short (two or three letters) so .that the lengths of constructed tags remain 
manageable. 

The type tag denotes the type of the variable or constant, of course. The name of the type is 
just the type tag. Note that the first letters of type names are capitalized. For example, in: 

cpMac: Cp 

the "cp" is the tag, "Mac" is a modifier. "Cp" is the name of the type. 

Modifiers are used to distinguish variables in some scope (record, local, or global frame) which 
have the same type. Single digits or numbers may be used as modifiers in some cases. Some 
modifiers imply standard semantics, as described below. If there is just one value of a given 
type in some scope, the modifier should be left empty; e.g. 

write GetObject(nh: Nh) instead of GetObject(nhObject: Nh) 

If constructed tags get too long and cumbersome, a new tag may be defined to stand for the 
complex type. 

Painting (particularizing) of types is done by the modifier. For example the nh of a pi is 
written as: nhPl. This is not a type construction, therefore PI is capitalized. The type of nhPl 
is Nh, of course. 

To express repeated painting and modifying of quantities, the modifiers should be concatenated 
in the order of construction (the earliest modifier first). Eg: hrFreeMin: an hr, painted Free; 
then the hrFree modified by Min. 
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12. Standard types (and constants) are defined in StandardDefs: 

F: TYPE s BOOLEAN; ~ Flag 

W: TYPE s CARDINAL; ~ Unsigned word 

INT: TYPE = INTEGER; ~ Handy abbreviation, not a tag 

VrF: TYPE = {vrTrue, vrFalse}; — Used for certain variant fields 

InNil: TYPE = [0..0); — Domain for variable size arrays 

~ Powers of 2, to be used in field definitions 
w2to0: W = 1; 
w2tol: W = 2; 
w2to2: W = 4; 

w2tol5: W = 100000B; 

13. The standard type constructions are the following: (X and Y denote arbitrary tags, 
througout). 

pX type is declared as: ORDERED POINTER T& X 

Pamterte-OC Let t be the indirection operation. pXt is then an X. 

aX type is declared the same as X, with initial POINTER removed 

A structure pointed to by X. paX would be an X. Used for declaring larger records, a 
in conjunction with mp or rg (see below) is used to declare arrays. 

bX type is declared as: INT \ » 

Based X. There exists some pointer Y such that Y+bX is an X. Used, for example, to 
name relative pointers to fields in records which have fields of varying sizes. 

bXY type is declared as: INT€<$Jr$L 

Based X. Same as above, with the type of the base given. -7 

cX type is declared as: W or INTE^E^ qCo ' 

Counts instances of X (not necessarily all instances). For example, ceo could be a 
counter counting colors which appear in a graph (assuming the type definition co = 
{coRed, coGreen, coBlue}). 

dX type is declared as: INT £65 £ A&S-^ 1 ^^^ 

First difference of X. X + dX is an X ^*^^ 

mpXY type is declared as PeW4^ft^© a- 1^RAY InX OF Y 

Array (map) with domain X and range Y. The domain InNil is specified if the array 
is of variable size. mpXYt[X] is a Y. Note that ampXY is an ARRAY InX OF Y, 
ampXY[X] is a Y. 

InX type is declared as [O..XMax) 

This is a type construction only, for use in array declarations and loops. There need 
not be any values of type InX. "In" stands for "index", "interval", and "IN" (as in 
FOR ALL x IN InX DO). See below for XMax. 

rgX short for mpiXX, array with domain iX and range X. 

iX type is declared as: INT^JT^ 

Domain of rgX. Not defined to be an interval, so that XNil, XMac, and XMax, all of 
which are, strictly speaking, outside of the domain of rgX, can all be declared IX. 
Same is true for other index types, that is for any tag X which appears in the domain 
of a map mpXY. 

IX type is declared as: INTERS:* 

Length of an instance of X in words. 

tX temporary X, the same type as X. A somewhat unelegant but efficacious device to 

distinguish between parameters and local (temporary) variables in procedures, without 
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APPENDIX A, continued: DIAMOND Template 

Pack: set of Mesa modules implementing an abstraction. 
Reasons for more than one module/pack: 

1. single module may be too small to hold all operations 

2. the frequency of usage (and core residency) may be different for groups of 
operations. In particular, initialization should, in most cases, be separated 
from the frequently used operations. 

A Pack implementing the Abstraction Xy would consist of the following modules: 

Xy containing the declaration of the Xy structure and the most frequently 

used operations 
Xyl no declarations, more operations of the data structure. Reasons for 

split from Xy, as above. 
Xy2 2nd split, and so on. 

Xylnit initialization and binding code 

XyTest test output and check procedure code (same format as xyl) 

XyDefs contains the type declarations and external interface definition 

(externally used operations in Xy, Xyl etc.) 
XyPriv private type declarations and internally used operations in Xy, Xyl etc. 

Module named XX would be stored in file xx.mesa. The command file to be executed 
when xx.mesa is changed is xx.cm. Under current operational procedures, the 
command files are created by the programmer at the same time as the corresponding 
source file, and contain the following: 



xy.cm 

xyl.cm 

xyinit.cm 

xytest.cm 

xydefsxm 


? 
? 
? 

similar to xyl 
? 


xyprivxm 


? 



Module templates follow. The standard formatting for Mesa files is (single 
paragraph/module): 

Margins: L: 85pt R: 580pt f >' J Q 
Lead: X: Ipt Y: Opt 
Tabs: Plain-tabs: 55pt 
Font: 

Other formatting rules are described in mesa-rules.memo. 

The suggested use of the template is as follows: start creating the pack by editing the 
template, scrolling back and forth between definitions, declarations, initialization, and 
code. For smaller packs, it may be worthwhile to save the pack as a whole on a .pack 
file. When ready to compile, select a niodu!$Jk>i^j^\g™ copy it into a 

new window and write it on the correct .mesafiie! FpTtKer edits may be made on the 
saved .pack or .mesa file (but not interchangeably) ay it is convenient. 

,^ ?0 



ho\ 
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-- X Y 



DIRECTORY 

— Pack Specific 

XyDefs: FROM "xydefs", 
XyPriv: FROM "xypriv", 

— Module Specific 

Standard Defs: FROM "standarddefs"; 

DEFINITIONS FROM 

— Pack Specific 

XyDefs, 

XyPriv, 

-- Module Specific 

Standard Defs; 

~ END OF DIRECTORY 

Xy: 

PROGRAM s 
BEGIN 

— Pack Data Structure 
ninl: Nm; 



— Pack Operations 

— OP ONE 

OpOne: 

PUBLIC PROCEDURE [nml: Nm, nm2: Nm] RETURNS [Nm] 



•"7 BEGIN 
I nm3: Nm; 



Proc: PROCEDURE = 

BEGIN 
END; -- OF Proc 



IF nml THEN 

BEGIN 
END; 

-I END; ~ OF OpOne 



—OP TWO 

OpTwo: 

END; — OF OpTwo 



-- Private Operations 
-- O P THREE 
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OpThree: 

PROCEDURE [nml: Nm, nm2: Nm] RETURNS [Nm] 
f BEGIN 

' END; — OF OpThree 



•1 



END. ~ OF Xy 
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— X Y 1 



DIRECTORY 

— Pack Specific 

XyDefs: FROM "xydefs", 
XyPriv: FROM "xypriv", 
Xy: FROM "xy", 

— Module Specific 

Standard Defs: FROM "standarddefs"; 

DEFINITIONS FROM 

— Pack Specific 

XyDefs, 
XyPriv, 

— Module Specific 

StandardDefs; 

— END OF DIRECTORY 

Xyl: 

PROGRAM [xy: POINTER TO FRAME [Xy]] SHARING Xy 

BEGIN OPEN xy; 



— Pack Operations 
-OP FOUR 
Op Four: 
END; — OF OpFour 



Private Operations 



END. - OF Xyl 



X Y I N I T 
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DIRECTORY 

— Pack Specific 

XyDefs: 

XyPriv: 

Xy: 

Xyl: 

Xy2: 

XyTest: 

— Module Specific 

ControlDefs: 
StandardDefs: 



FROM "xydefs", 
FROM "xypriv", 
FROM "xy", 
FROM "xyl", 
FROM "xy2", 
FROM "xytest", 



FROM "controldefs", 
FROM "standarddefs"; 



DEFINITIONS FROM 
-- Pack Specific 

XyDefs, 

XyPriv, 

— Module Specific 

ControlDefs, 
StandardDefs; 

— END OF DIRECTORY 

Xylnit: 

PROGRAM [nm: Nm] SHARING Xy, Xyl, Xy2, XyTest 

BEGIN 



SetBindingEntry: 



EXTERNAL PROCEDURE [frame, entry: GlobalFrameHandle]; 



-- Private Operations 
-- I N I T 



7 



Init: 

PROCEDURE = 
BEGIN 

-- Local Declarations 

nm: Nm; 

yzlnit: POINTER TO FRAME [Yzlnit]; - 

xy: POINTER TO FRAME [Xy]; 

xyl: POINTER TO FRAME [Xyl]; 

xy2: POINTER TO FRAME [Xy2]; 

xytest: POINTER TO FRAME [XyTest]; 

xylnit: POINTER TO global FrameBase; 

-- Remove Self From Binding Path 

xylnit <- REGISTER[Greg]; 
SetBindingEntry[xyInit, xylnit.bindlink]; 

— Initialize "Owned" Modules 



"Owned" Module 
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yzlnit <- NEW Yzlnit[...]; 
BIND yzlnit; START yzlnit; 

— Instantiate Pack 

xy <- NEW Xy[]; 

xyl *- NEW Xyl[xy]; 

xy2 *• NEW Xy2[xy"]; 

xytest «• NEW XyTest[xy]; 

SetBindingEntry[xylnit.ownerlink, xylnitbindentry]; 

BIND xy; 

BIND xyl; 

BIND xy2; 

BIND xytest; 

-- Initialize Pack Data Structure 

BEGIN OPEN xy, xyl, xy2, xytest; 

[(initialization code) 

2ND; - OF OPEN xy 

END; — OF Init 



InitQ 

END. -- OF Xylnit 
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- X Y D E F S 

DIRECTORY 

Standard Defs: FROM "standarddefs"; 

DEFINITIONS FROM 

Standard Defs; 

- END OF DIRECTORY 

XyDefs: 

DEFINITIONS = 
BEGIN 

~ Abstractions 

Nm: TYPE = INT; 

nmNil: Nm = -1; 

- Operations 

OpOne: PROCEDURE [nml: Nm, nm2: Nm] RETURNS [Nm]; 
END. — OF XyDefs 
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— X Y P R I V 

DIRECTORY 

XyDefs: FROM "xydefs", 

StandardDefs: FROM "standarddefs"; 

DEFINITIONS FROM 
XyDefs, 
StandardDefs; 

~ END OF DIRECTORY 

XyPriv: 

DEFINITIONS = 
BEGIN 

— Abstractions 

Nm: TYPE = INT; 

— Operations 

OpThree: PROCEDURE [nml: Nm, nm2: Nm] RETURNS [Nm]; 
END. - OF XyPriv 
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—STANDARD DEFS 



Standard Defs: 




DEFINITIONS 


= 


BEGIN 






— Abstractions 




F: 


TYPE = BOOLEAN; 


W: 


TYPE = UNSPECIFIED; 


Ch: 


TYPE = CHARACTER; 


Sm: 


TYPE = STRING; 


INT: 


TYPE = INTEGER; 


VrF: 


TYPE = {vrFalse, vrTrue}; 


InNil: 


TYPE = [0..0); 


w2to0: 


W = 


IB; 


w2tol: 


W = 


2B; 


w2to2: 


W = 


4B; 


w2to3: 


W = 


10B; 


w2to4: 


w = 


20 B; 


w2to5: 


w = 


40 B; 


w2to6; 


w = 


100B; 


w2to7: 


w = 


200B; 


w2to8: 


w = 


400B; 


\v2to9: 


w = 


1000B; 


w2tol0 


w = 


2000B; 


w2toll 


w = 


4000B; 


w2tol2 


w = 


10000B; 


w2tol3 


w = 


20000B; 


w2tol4 


w = 


40000B; 


w2tol5 


w = 


100000B; 



END. — OF Standard Defs 
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Appendix A, continued: DIAMOND Dictionary 
To Be Supplied Next Week By C. Simonyi 



RACK 

see hz.spec, hzdefs.mesa 

hz heap global frame 

ahf block descriptor 

hf pointer to ahf 

hff pointer to free ahf 

hfn pointer to normal ahf 

hr pointer to block 

h pointer to hr = pointer to pointer to block 

hx convertible finger 

rghx finger table 

ihx index into rghx 

nh pointer to hx 

hzace hz-type ace 

hzce pointer to hzace 

CACHES 

see ca.spec, cadefs.rnesa 

ca cache global frame 

nw name of whatever is being cached 

lu last used time 

ace cache entry descriptor 

ce cache entry, pointer to ace 

rgce cache entry array 

ice index into rgce 

rgace descriptor array 

OBJECT SWAPPING 

see nsg.spec. nsgdefs.mesa 

ns name of swapable object 

sns object segment 

rgsns segment array 

isns index into rgsns 

dv/ segment chunk size 

PAGE SWAPPING 

see pbg.spec, pbgdefs .mesa 

np name of page 

snp page segment 

rgsnp segment array 

isnp index into rgsnp 

fl file descriptor 

rgfl array of fl 

ifl index into rgfl 

fp file pointer 

fpn file page number 

rv/ relative word in page 

frw relative word in file 

pb page buffer = [array[256] , np] 

hrpb pointer to pb 

hpb pointer to pointer to pb 

pbgace pbg-type ace 

pbgce pointer to pbgace 

fh file handle 

sh stream handle 
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Appendix B: TOOLS Special Convention Setion 
To Be Supplied Next Week By C. Irby 
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Appendix C: Mesa Runtime Special Convention Setion 
To Be Supplied Next Week By C. Irby 



